<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<!-- Note: RELEASE_VERSION and DATE are set by ant -->

<head>
  <title>The Berkeley DB Java Edition Package: BDB JE Library Version
  11.2.4.1 (Release 4.1.7) Change Log</title>
  <meta name="description"
        content="Berkeley DB, Java Edition: A database programmatic toolkit.">
  <meta name="keywords"
        content="embedded,database,programmatic,toolkit,b+tree,btree,transaction,transactions,locking,access method,access methods,java">
</head>
<body bgcolor="white">

<h2 align="center">Oracle Berkeley DB Java Edition 11G R2 Change Log
</h2>
<p align="center">Library Version 11.2.4.1,  Release 4.1.7</p>

<!-- =================================================== -->
<hr>
<h3 align="center"><u>Changes in 4.1.7</u></h3>
<!-- =================================================== -->

<h3>General Changes</h3>
<ol>

<li>
Fix a bug that could cause an <code>EnvironmentFailureException</code> with
<code>LOG_FILE_NOT_FOUND</code> during recovery, meaning that the JE
environment cannot be opened.  We strongly recommend that all applications
using JE 4.1.6 upgrade immediately.  The bug was introduced in JE 4.1.6 and is
not present in earlier releases.  [#19346]
</li><br>

<li>
Fixed a bug that prevents using a DPL class converter mutation for a proxy
class.  Previously, an exception such as the following was thrown:
<pre>
Exception in thread "main" java.lang.ClassCastException:
com.sleepycat.persist.raw.RawObject cannot be cast to
com.sleepycat.persist.model.PersistentProxy
at com.sleepycat.persist.impl.ProxiedFormat.newInstance(ProxiedFormat.java:91)
at com.sleepycat.persist.impl.RecordInput.readObject(RecordInput.java:174)
at com.sleepycat.persist.impl.ReflectionAccessor$ObjectAccess.read(ReflectionAccessor.java:406)
at com.sleepycat.persist.impl.ReflectionAccessor.readNonKeyFields(ReflectionAccessor.java:285)
...
</pre>
Thanks to James Li for
<a href="http://forums.oracle.com/forums/thread.jspa?forumID=273&threadID=2126809">reporting</a>
this on OTN and helping us to identify the problem in the source code.
[#19312]
</li><br>

<li>
Fix a bug that caused a hard deadlock when attempting to abort a transaction in
one thread, while performing operations using the transaction in another
thread.  Now, rather than a hard deadlock, an IllegalStateException will be
thrown in this circumstance.  Thanks to Jervin on OTN for
<a href="http://forums.oracle.com/forums/thread.jspa?threadID=2130900">reporting</a>
this.
[#19321]
</li><br>

</ol>

<!-- =================================================== -->
<hr>
<h3 align="center"><u>Changes in 4.1.6</u></h3>
<!-- =================================================== -->
<h3>Performance Enhancements</h3>

When a BDB JE application has a data set that does not fit entirely in
cache, AND there is no particular working set of data that fits in
cache, the application will see the best performance when as much of the
internal btree nodes, or index, are kept in cache. This release
includes improvements to make JE's cache management more efficient,
and provides statistics to help determine cache efficiency.
<ol>
<li>
Added concurrent eviction, which can be a benefit to any BDB JE
application whose data set does not fit in cache.  In past releases,
cache eviction has been carried out by JE daemon threads, application
threads which call JE operations, and an optional single evictor
thread. The actual eviction operation was serialized, and could create
a bottleneck where many threads could be seen waiting upon the method
com.sleepycat.je.evictor.Evictor.doEvict().
<p>
In this release, cache eviction is no longer serialized, and can be
executed concurrently. In addition, JE now has a dedicated,
configurable thread pool which will do cache eviction when memory
limits are reached. Eviction is done by this dedicated pool, by other
JE daemon threads, and by application threads. JE attempts to skew the
eviction workload toward the pool and daemon threads, in order to
offload application threads. 
<p>
The eviction pool is enabled by default, but can be disabled by the
je.env.runEvictor property. The properties je.evictor.coreThreads,
je.evictor.maxThreads and je.evictor.keepAlive are used to configure
the core, max and keepalive attribute for the pool. EnvironmentStats
has new statistics that try to give an indication of whether eviction
is executed by the eviction pool, by operations with specific
com.sleepycat.je.CacheMode settings, by explicit calls to
Environment.evictMemory, by operations that will cause the cache to go
over budget, or by JE daemon threads. [#18626]
</li><br>
<li>
This release introduces several new kinds of in-memory btree node
compression, targeted toward reducing the memory needed to hold
internal btree nodes in cache. This is particularly helpful for
applications which have data sets which do not fit in cache.
<p>
One of the optimizations reduces the in-memory footprint of an internal
btree node when only a small portion of it has been referenced, as
might be the case when data records are accessed in a random order, or
when a subset of data is accessed. It does not help if the
application is doing a database-wide cursor traversal. [#18623]
<p>
Another optimization takes effect when the key less than or equal to
16 bytes in size, which can be true either when the key is naturally
small, or when key prefixing is enabled through
Database.setKeyPrefix(). [#18624]
</li><br>
<li>
Optimized <code>Database.sync</code> and <code>Database.close</code>
for deferred-write databases, so that no file write or fsync is
performed if nothing in the database is dirty.  Calling these methods
will now have very low cost when no changes to the database have been
made. [#18402]
</li><br>
<li>
The javadoc
for <a href="http://download.oracle.com/docs/cd/E17277_01/html/java/com/sleepycat/je/Durability.html">com.sleepycat.je.Durability</a>
states that COMMIT_NO_SYNC is the default durablity for replicated
transactions.The documentation is correct, but the actual default used
was incorrect, and was COMMIT_SYNC. This has been fixed. [#18900]
</li>
</ol>
<h3>General Changes</h3>
<ol>
<li>
The following exception could be seen in rare circumstances from a
replicated environment. It is not an actual error, and was the result
of an over zealous assertion. The assertion has been corrected.
<pre>

&lt;DaemonThread name="INCompressor"/&gt; caught exception: 
 com.sleepycat.je.EnvironmentFailureException:
 Node 1(1):rrep0 Read invisible log entry at 0x98c/0x2c711 
&lt;hdr type="LN_TX/7" &lt;lsn v="6,505,875"&gt; 
 isInvisible="1" prev="0x2c6dd" size="28" cksum="501157099"/&gt;
 LOG_INTEGRITY:
 Log information is incorrect, problem is likely
 persistent. fetchTarget of 0x98c/0x2c711 parent IN=55088 
IN class=com.sleepycat.je.tree.BIN lastFullVersion=0x9c2/0x24a54 parent.getDirty()=true state=1

at com.sleepycat.je.log.LogManager.getLogEntryFromLogSource(LogManager.java:927)
at com.sleepycat.je.log.LogManager.getLogEntry(LogManager.java:781)
at com.sleepycat.je.log.LogManager.getLogEntryAllowInvisibleAtRecovery(LogManager.java:742)
at com.sleepycat.je.tree.IN.fetchTarget(IN.java:1309)
at com.sleepycat.je.tree.BIN.fetchTarget(BIN.java:1321)
at com.sleepycat.je.tree.BIN.compress(BIN.java:804)
at com.sleepycat.je.incomp.INCompressor.compressBin(INCompressor.java:501)
at com.sleepycat.je.incomp.INCompressor.doCompress(INCompressor.java:411)
at com.sleepycat.je.incomp.INCompressor.onWakeup(INCompressor.java:341)
at com.sleepycat.je.utilint.DaemonThread.run(DaemonThread.java:162)
</pre>
</li><br>

<li>
Fixed a bug that causes a EnvironmentFailureException LOG_FILE_NOT_FOUND when
using a particular sequence of operations with a Database configured for
duplicates (DatabaseConfig.setSortedDuplicates(true)) or a DPL secondary key
with a MANY_TO_ONE or MANY_TO_MANY relationship.  The sequence of operations
that causes the bug is:
<ol>
    <li>A single record exists (no duplicates) for key A</li>
    <li>New transaction T1 starts</li>
    <li>Key A is deleted in T1</li>
    <li>Two or more duplicates are inserted for key A in T1</li>
    <li>The T1 transaction aborts</li>
</ol>
Later, the log file containing the original version of the record is cleaned
and deleted, causing an exception when that record is subsequently accessed.
An example stack trace is below.
<pre>
(JE 4.0.92) var/db/bdb_userNode fetchTarget of 0x3151/0x44b2638 parent
IN=729921304 IN class=com.sleepycat.je.tree.DBIN
lastFullVersion=0x3189/0x13616b0 parent.getDirty()=false state=0
LOG_FILE_NOT_FOUND: Log file missing, log is likely invalid. Environment is
invalid and must be closed.
at com.sleepycat.je.tree.IN.fetchTarget(IN.java:1241)
at com.sleepycat.je.tree.BIN.fetchTarget(BIN.java:1300)
...
</pre>
Thanks to "helg" on OTN for <a href="http://forums.oracle.com/forums/message.jspa?messageID=4477124">reporting</a>
this and working with us to diagnose the problem. [#17252] (fixed in 4.0.114)
</li><br>
<li>
Added documentation for the je.rep.node.priority configuration
property. [#17684] (fixed in 4.0.114)
</li><br>
<li>
Fixed a bug which could cause <code>PreloadStatus.EXCEEDED_TIME</code> to be
incorrectly returned from the <code>Database.preload()</code>
method. [#18577]
(fixed in 4.0.114)
</li><br> 


<li>Improved the exception thrown in the following case: JE does not
support opening an environment with first a non replicated and then a
replicated environment handle. For example, if the user executes these
statements in the following order:
<pre>
     Environment env = new Environment( envHome, envConfig)
     ReplicatedEnvironment repEnv = new ReplicatedEnvironment(envHome, repConfig, envConfig)
 </pre>
she would see a java.lang.ClassCastException, instead of the more
informative java.lang.UnsupportedOperationException. This has been
fixed. Note that it is permissible to open an environment as a
ReplicatedEnvironment, and then follow by opening it as a read only
Environment. This was initially reported on
the <a href="http://forums.oracle.com/forums/thread.jspa?threadID=1066406"
>OTN forum.</a>  [#18649]
</li></br>


<li>
Added the property <code>EnvironmentConfig.CLEANER_LAZY_MIGRATION</code> to
provide finer control over log cleaner, checkpointing and eviction
behavior.  See the javadoc for details.  [#18650]
(fixed in 4.0.114)
</li><br>
<li>
Fixed a bug that causes a fatal exception during recovery (opening of a JE
Environment) under certain conditions.  An example of the exception stack trace
is below.
<pre>
Exception in thread "main" com.sleepycat.je.EnvironmentFailureException:
(JE 4.0.92) last LSN=0x424/0xe4fc1 LOG_INTEGRITY: Log information is incorrect,
problem is likely persistent. Environment is invalid and must be closed.
    at com.sleepycat.je.recovery.RecoveryManager.traceAndThrowException(RecoveryManager.java:3052)
    at com.sleepycat.je.recovery.RecoveryManager.readINs(RecoveryManager.java:867)
    at com.sleepycat.je.recovery.RecoveryManager.buildINs(RecoveryManager.java:621)
    at com.sleepycat.je.recovery.RecoveryManager.buildTree(RecoveryManager.java:513)
    at com.sleepycat.je.recovery.RecoveryManager.recover(RecoveryManager.java:175)
    at com.sleepycat.je.dbi.EnvironmentImpl.finishInit(EnvironmentImpl.java:529)
    at com.sleepycat.je.dbi.DbEnvPool.getEnvironment(DbEnvPool.java:204)
    at com.sleepycat.je.Environment.makeEnvironmentImpl(Environment.java:230)
    at com.sleepycat.je.Environment.<init>(Environment.java:212)
    at com.sleepycat.je.Environment.<init>(Environment.java:166)
    ...
Caused by: com.sleepycat.je.EnvironmentFailureException: (JE 4.0.92)
fetchTarget of 0x89/0x4c2e29 parent IN=4883580 IN
class=com.sleepycat.je.tree.DIN lastFullVersion=0x424/0xdcec4
parent.getDirty()=false state=0 LOG_FILE_NOT_FOUND: Log file missing, log is
likely invalid. Environment is invalid and must be closed.
    at com.sleepycat.je.tree.IN.fetchTarget(IN.java:1241)
    at com.sleepycat.je.tree.DIN.fetchTarget(DIN.java:520)
    at com.sleepycat.je.tree.IN.findParent(IN.java:2704)
    at com.sleepycat.je.tree.Tree.getParentINForChildIN(Tree.java:879)
    at com.sleepycat.je.recovery.RecoveryManager.replayINDelete(RecoveryManager.java:1770)
    at com.sleepycat.je.recovery.RecoveryManager.replayOneIN(RecoveryManager.java:945)
    at com.sleepycat.je.recovery.RecoveryManager.readINs(RecoveryManager.java:846)
    ... 11 more
Caused by: java.io.FileNotFoundException: 00000089.jdb (The system cannot find
the file specified)
    at java.io.RandomAccessFile.open(Native Method)
    at java.io.RandomAccessFile.<init>(Unknown Source)
    at java.io.RandomAccessFile.<init>(Unknown Source)
    at com.sleepycat.je.log.FileManager$1.<init>(FileManager.java:993)
    at com.sleepycat.je.log.FileManager.openFileHandle(FileManager.java:992)
    at com.sleepycat.je.log.FileManager.getFileHandle(FileManager.java:888)
    at com.sleepycat.je.log.LogManager.getLogSource(LogManager.java:1073)
    at com.sleepycat.je.log.LogManager.getLogEntry(LogManager.java:779)
    at com.sleepycat.je.log.LogManager.getLogEntryAllowInvisibleAtRecovery(LogManager.java:743)
    at com.sleepycat.je.tree.IN.fetchTarget(IN.java:1225)
    ... 17 more
</pre>
<p>The bug only occurred under the following conditions:</p>
  <ul>
  <li>Databases with duplicates are used, including secondary indices.</li>
  <li>Many duplicate records are deleted in the same key range.</li>
  <li>The problem is most likely to occur when deletions occur immediately
      prior to closing the environment, and the environment is closed and
      re-opened frequently.</li>
  </ul>
<p>No data loss occurs as a result of this bug.  By using a version of JE with
the bug fix, such environments can be opened and used normally.  Thanks to OTN
user justindthomas for reporting the problem and working with us to diagnose
and fix it.  [#18663] (fixed in 4.0.114)</p>
</li><br>
<li>
Fixed a bug that causes an <code>IllegalStateException</code> when a DPL
<code>Converter</code> mutation is used for class evolution, and Replicas are
upgraded first (as prescribed) in a replication group. [#18690]
(fixed in 4.0.114)
</li><br>
<li>
Fixed a bug which can make log utilization inaccurate and prevent log cleaning,
when <code>Environment.removeDatabase</code> or
<code>Environment.truncateDatabase</code> is called, and the program crashes or
exits before any other information is written to disk.  For example, if the
Environment is closed normally after the removal/truncation, or a scheduled
checkpoint occurs, then the bug will <em>not</em> occur. [#18696]
(fixed in 4.0.114)
</li><br>
<li>
<p>All public JE exception and statistics classes should be
  serializable. Some were not, and have been fixed. The following
  classes are now certified to be serializable. [#18738]
<ul>
    <li><code>com.sleepycat.je.BtreeStats</code></li>
    <li><code>com.sleepycat.je.CommitToken</code></li>
    <li><code>com.sleepycat.je.DatabaseEntry</code></li>
    <li><code>com.sleepycat.je.DatabaseException</code></li>
    <li><code>com.sleepycat.je.DatabaseExistsException</code></li>
    <li><code>com.sleepycat.je.DatabaseNotFoundException</code></li>
    <li><code>com.sleepycat.je.DatabaseStats</code></li>
    <li><code>com.sleepycat.je.DeadlockException</code></li>
    <li><code>com.sleepycat.je.DeleteConstraintException</code></li>
    <li><code>com.sleepycat.je.DuplicateDataException</code></li>
    <li><code>com.sleepycat.je.EnvironmentFailureException</code></li>
    <li><code>com.sleepycat.je.EnvironmentLockedException</code></li>
    <li><code>com.sleepycat.je.EnvironmentNotFoundException</code></li>
    <li><code>com.sleepycat.je.EnvironmentStats</code></li>
    <li><code>com.sleepycat.je.ForeignConstraintException</code></li>
    <li><code>com.sleepycat.je.LockConflictException</code></li>
    <li><code>com.sleepycat.je.LockNotAvailableException</code></li>
    <li><code>com.sleepycat.je.LockNotGrantedException</code></li>
    <li><code>com.sleepycat.je.LockStats</code></li>
    <li><code>com.sleepycat.je.LockTimeoutException</code></li>
    <li><code>com.sleepycat.je.LogWriteException</code></li>
    <li><code>com.sleepycat.je.OperationFailureException</code></li>
    <li><code>com.sleepycat.je.PreloadStats</code></li>
    <li><code>com.sleepycat.je.PreloadStatus</code></li>
    <li><code>com.sleepycat.je.RunRecoveryException</code></li>
    <li><code>com.sleepycat.je.SecondaryConstraintException</code></li>
    <li><code>com.sleepycat.je.SecondaryIntegrityException</code></li>
    <li><code>com.sleepycat.je.SecondaryReferenceException</code></li>
    <li><code>com.sleepycat.je.SequenceExistsException</code></li>
    <li><code>com.sleepycat.je.SequenceIntegrityException</code></li>
    <li><code>com.sleepycat.je.SequenceNotFoundException</code></li>
    <li><code>com.sleepycat.je.SequenceOverflowException</code></li>
    <li><code>com.sleepycat.je.SequenceStats</code></li>
    <li><code>com.sleepycat.je.ThreadInterruptedException</code></li>
    <li><code>com.sleepycat.je.TransactionStats</code></li>
    <li><code>com.sleepycat.je.TransactionStats.Active</code></li>
    <li><code>com.sleepycat.je.TransactionTimeoutException</code></li>
    <li><code>com.sleepycat.je.UniqueConstraintException</code></li>
    <li><code>com.sleepycat.je.VersionMismatchException</code></li>
    <li><code>com.sleepycat.je.XAFailureException</code></li>
    <li><code>com.sleepycat.je.jca.ra.JEException</code></li>
    <li><code>com.sleepycat.je.rep.DatabasePreemptedException</code></li>
    <li><code>com.sleepycat.je.rep.GroupShutdownException</code></li>
    <li><code>com.sleepycat.je.rep.InsufficientAcksException</code></li>
    <li><code>com.sleepycat.je.rep.InsufficientLogException</code></li>
    <li><code>com.sleepycat.je.rep.InsufficientReplicasException</code></li>
    <li><code>com.sleepycat.je.rep.LockPreemptedException</code></li>
    <li><code>com.sleepycat.je.rep.LogOverwriteException</code></li>
    <li><code>com.sleepycat.je.rep.MasterStateException</code></li>
    <li><code>com.sleepycat.je.rep.MemberNotFoundException</code></li>
    <li><code>com.sleepycat.je.rep.ReplicaConsistencyException</code></li>
    <li><code>com.sleepycat.je.rep.ReplicaWriteException</code></li>
    <li><code>com.sleepycat.je.rep.ReplicatedEnvironmentStats</code></li>
    <li><code>com.sleepycat.je.rep.RestartRequiredException</code></li>
    <li><code>com.sleepycat.je.rep.RollbackException</code></li>
    <li><code>com.sleepycat.je.rep.RollbackProhibitedException</code></li>
    <li><code>com.sleepycat.je.rep.StateChangeException</code></li>
    <li><code>com.sleepycat.je.rep.UnknownMasterException</code></li>
    <li><code>com.sleepycat.je.util.LogVerificationException</code></li>
    <li><code>com.sleepycat.persist.IndexNotAvailableException</code></li>
    <li><code>com.sleepycat.persist.StoreExistsException</code></li>
    <li><code>com.sleepycat.persist.StoreNotFoundException</code></li>
    <li><code>com.sleepycat.persist.evolve.DeletedClassException</code></li>
    <li><code>com.sleepycat.persist.evolve.IncompatibleClassException</code></li>
</ul>
(fixed in 4.0.114)
</li><br>
<li>
Fixed a bug which caused a <code>NullPointerException</code> under certain
circumstances when key prefixing is enabled. This was originally reported on the
<a href="http://forums.oracle.com/forums/thread.jspa?messageID=4364842">
OTN Forum</a>. [#18773]
(fixed in 4.0.114)
</li><br>
<li>
Fixed a bug that caused log cleaner threads to hang with the following
stack trace. This could occur infrequently in applications which use
EnvironmentMutableConfig.setExceptionListener() and have a high level
of concurrent log cleaning.
 [#18791]
(fixed in 4.0.114)
<pre>
   java.lang.Thread.State: RUNNABLE
        at java.util.HashMap.put(HashMap.java:374)
        at java.util.HashSet.add(HashSet.java:200)
        at com.sleepycat.je.dbi.EnvironmentImpl.registerExceptionListenerUser(EnvironmentImpl.java:730)
        at com.sleepycat.je.utilint.DaemonThread.<init>(DaemonThread.java:60)
        at com.sleepycat.je.cleaner.FileProcessor.<init>(FileProcessor.java:110)
        at com.sleepycat.je.cleaner.Cleaner.doClean(Cleaner.java:461)
        at com.sleepycat.je.dbi.EnvironmentImpl.invokeCleaner(EnvironmentImpl.java:1879)
        at com.sleepycat.je.Environment.cleanLog(Environment.java:1559)
 </pre>
</li><br>
<li>
Fixed a problem where Database.count() could return the wrong value
for replicated databases with duplicates, after the environment had
experienced a replication rollback. [#18816]
(fixed in 4.0.114)
</li><br>
<li>
Fixed a problem which was intermittent and seen only on the master
node of a replication group which using synchronous transaction
commits. The application would see the following stack trace. The
problem was transient, no data was lost, and the system could re-open 
successfully. [#18882]
(fixed in 4.0.114)
<pre>
java.io.FileNotFoundException: ... (The system cannot find the file specified)
    at java.io.RandomAccessFile.open(Native Method)
    at java.io.RandomAccessFile.<init>(Unknown Source)
    at java.io.RandomAccessFile.<init>(Unknown Source)
    at com.sleepycat.je.log.FileManager$1.<init>(FileManager.java:998)
    at com.sleepycat.je.log.FileManager.openFileHandle(FileManager.java:998)
    at com.sleepycat.je.log.FileManager.getFileHandle(FileManager.java:893)
    at com.sleepycat.je.rep.stream.FeederReader$SwitchWindow.fillNext(FeederReader.java:523)
    at com.sleepycat.je.log.FileReader.readData(FileReader.java:758)
    at com.sleepycat.je.log.FileReader.readNextEntryAllowExceptions(FileReader.java:259)
    at com.sleepycat.je.log.FileReader.readNextEntry(FileReader.java:230)
    at com.sleepycat.je.rep.stream.FeederReader.scanForwards(FeederReader.java:284)
    at com.sleepycat.je.rep.stream.MasterFeederSource.getWireRecord(MasterFeederSource.java:62)
    at com.sleepycat.je.rep.impl.node.Feeder$OutputThread.run(Feeder.java:659)
</pre>
</li><br>
<li>
When a disk corruption occurs that overwrites a log entry with non-zero data, a
checksum error is now properly reported via an EnvironmentFailureException, and
tools such as DbScavenger and DbVerifyLog work properly.  Earlier, if a
corruption overwrote specific parts of the log entry, another exception was
mistakenly throw, such as:
<pre>
java.lang.ArrayIndexOutOfBoundsException at
java.util.zip.Adler32.update(Adler32.java:47) at
com.sleepycat.je.log.ChecksumValidator.update(ChecksumValidator.java:59) at
com.sleepycat.je.log.ChecksumValidator.update(ChecksumValidator.java:55) at
com.sleepycat.je.log.LogManager.getLogEntryFromLogSource(LogManager.java:928)
...
</pre>
Thanks to Jean-Christophe on OTN for reporting this bug.
(fixed in 4.0.114)
</li><br>

<li> 
Opening a com.sleepycat.bind.serial.StoredClassCatalog on a replica
node in a JE HA replication group incorrectly resulted in a
ReplicaWriteException. This has been fixed.
Thanks to user13067358 on OTN for 
<a href="http://forums.oracle.com/forums/thread.jspa?forumID=273&threadID=1110050">
reporting this problem.</a> [#18938]
(fixed in 4.0.114)
</li><br>
<li> 
A DPL class evolution bug caused an exception or incorrect behavior when
renaming a field, when the name change caused the alphabetical order of fields
in the class to change.  An example of such an exception follows.  However,
other types of exceptions could also occur.
<pre>
java.lang.IllegalArgumentException: Can not set java.lang.Integer field 
com.sleepycat.persist.test.EvolveClasses$RenameSecField.new_secKey2 to java.lang.String
at java.lang.reflect.Field.set(Field.java:657)
at com.sleepycat.persist.impl.ReflectionAccessor$ObjectAccess.read(ReflectionAccessor.java:422)
at com.sleepycat.persist.impl.ReflectionAccessor.readSecKeyFields(ReflectionAccessor.java:253)
at com.sleepycat.persist.impl.ComplexFormat$EvolveReader.readObject(ComplexFormat.java:2127)
at com.sleepycat.persist.impl.PersistEntityBinding.readEntity(PersistEntityBinding.java:115)
at com.sleepycat.persist.impl.PersistEntityBinding.entryToObjectInternal(PersistEntityBinding.java:83)
at com.sleepycat.persist.impl.PersistEntityBinding.entryToObject(PersistEntityBinding.java:64)
at com.sleepycat.persist.PrimaryIndex.get(PrimaryIndex.java:597)
at com.sleepycat.persist.PrimaryIndex.get(PrimaryIndex.java:584)
...
</pre>
This has been fixed. [#18961]
(fixed in 4.0.114)
</li><br>

<li>
Fixed a bug that causes <code>Cursor.getNextDup</code> or
<code>EntityCursor.nextDup</code> to advance to a following key under certain
rare conditions.  This also has a side effect of causing
<code>Database.delete</code> to delete duplicate records for the following key
under the same conditions.  The conditions that lead to the bug are:
<ol>
    <li>A Database is configured for duplicates or a DPL secondary key with a
    <code>MANY_TO_XXX</code> relationship is used.</li>
    <li>The environment or transaction is explicitly configured for
    Serializable Isolation (this is not the default isolation mode).</li>
    <li>One or more records for key A exist.</li>
    <li>The key following key A, key B, has two or more duplicates, and the
    first duplicate for key B is deleted.</li>
    <li>Timing and conditions are such that the deleted duplicate for key B has
    not been internally compressed out of the Btree.</li>
    <li><code>Cursor.getNextDup</code> or <code>EntityCursor.nextDup</code> is
    called when positioned on the last record for key A, or
    <code>Database.delete</code> is called for key A.  In this case, the
    record(s) with key B will mistakenly be returned or deleted.</li>
</ol>
[#19026]
(fixed in 4.0.114)
</li><br>

<li>
Fixed a DPL bug that prevented use of a non-public persistent class.
Previously, an exception such as the following was thrown when the
constructor was public but the class was non-public.
<pre>
...
Caused by: java.lang.IllegalAccessException: Class
com.sleepycat.persist.impl.ReflectionAccessor can not access a member of class
XXX with modifiers "public"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
at java.lang.reflect.Constructor.newInstance(Constructor.java:505)
at com.sleepycat.persist.impl.ReflectionAccessor.newInstance(ReflectionAccessor.java:151)
...
</pre>
Thanks to Sheila on OTN for
<a href="http://forums.oracle.com/forums/thread.jspa?threadID=1123932">reporting</a>
this problem and working with us. [#19100]
</li><br>

<li>
After changing stats collection settings on the JE JConsole plugin,
the user may see a delay before the jconsole tab is repainted and
changes take effect.  This has been improved to provide a more
immediate response. [#19101]
</li><br>

<li>
Fixed a rare problem that could possibly cause a LogFileNotFoundException
if the following actions occurred in a very particular ordering:
<ul>
<li>The environment has been a replica in a JE replication group.
<li>There has been a master failover, resulting in a syncup in this
  replica.
<li>During syncup, there was a partial rollback of an in progress transaction.
<li>The transaction deleted and then inserted the same key value.
<li>Log cleaning occurs later.
</ul>
[#19160]
</li><br>
<li>
The javadoc for com.sleepycat.je.rep.ReplicatedEnvironment referred to a
je.rep.group.joinGroupTimeout property. That property doesn't exist,
and the documentation has been corrected to refer to je.rep.envSetupTimeout.
</li><br>
<li>
In a JE replication system, it was possible in some cases for a master
node to transfer to replica state and fail to properly reinitialize
internal state. The problem is that some data record locks were not
properly released, and future access to those data records could cause
deadlocks.
<p>
To resolve this, a new exception,
com.sleepycat.je.rep.MasterReplicaTransitionException is thrown in these
cases. MasterReplicaTransitionException is a RestartRequiredException, and the
application must close and reopen its environment handle, thereby
properly reinitializing the node. [#19177]
</li><br>

<li>
Fixed a bug that replicated parameters in je.properties can't be recognized if
opening a read only standalone Environment on a replicated Environment home.
[#19080]
</li><br>

</ol>
</body>
</html>
